home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 82 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. From: horstman@jupiter.SJSU.EDU (Cay S. Horstmann)
  2. Message-ID: <4du1v6$h74@jupiter.SJSU.EDU>
  3. X-Original-Date: Sun, 21 Jan 1996 18:43:05 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 21 Jan 96 23:03:54 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: STL still in standard
  9. Organization: San Jose State University - Math/CS Dept
  10. References: <4dd7on$djk@rc1.vub.ac.be> <4dgrb4$a2e@engnews1.Eng.Sun.COM> <9601171106.AA12639@lts.sel.alcatel.de>
  11. X-Newsreader: Forte Free Agent 1.0.82
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMQLGbeEDnX0m9pzZAQE6ywF5ASnscOoUT0cNxP/UsNOXl3sJYkrRO5Yh
  14.     2SlUghuT6j8tS1PWZrZbeN0ZoZKJ3ZQ6
  15.     =XoYK
  16.  
  17. James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
  18.  
  19. >Safer implementations are possible; Cay Horstman, I think, has already
  20. >made one available.  
  21.  
  22. Indeed. It works nicely as a debugging tool, and is 100% compatible
  23. with plain STL. Think of it as an "assert" for STL. It is available
  24. from http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html. A
  25. number of people at NYU have ported it to g++. If there is interest,
  26. I'll find out how far they got. 
  27.  
  28. >Exception safe implementations are also possible.
  29. >(It is also an open question how far one wants to go here.  I would
  30. >accept, for example, that an exception from the comparison function
  31. >when inserting into a map results in undefined behavior; if comparison
  32. >can throw an exception, an STL map is perhaps not the appropriate
  33. >container.)
  34.  
  35. I am not sure exceptions are the way to go--the great value of a
  36. standard is that it is, well, standard. STL may not be the greatest
  37. library on the planet, but it is certainly good enough, and it is
  38. standard. I don't like the idea of tinkering with the interface by
  39. adding exceptions.
  40.  
  41. My model here is the C string.h library. Consider strncpy. Could you
  42. imagine a dumber function? If either of the arguments is null, it
  43. dumps core. 99% of strncpy uses in my programs are of the form
  44.     strncpy(buffer, s, sizeof(buffer));
  45.     buffer[sizeof(buffer) - 1] = 0;
  46. Sure, in 1% of the cases, I am glad it doesn't add the terminating 0,
  47. but in 99% of the cases I hate it. But did I go out and write my own
  48. superior replacement of strncpy? I did for a while and all of my team
  49. members protested. They didn't want to learn my pet library. So I am
  50. back to strncpy. Like Bjarne Stroustrup wrote, library design is
  51. language design. 
  52.  
  53. Same with STL. I'd rather not figure out subtle differences between
  54. customized STL versions, especially with something as subtle as
  55. exception specifications. If it is a good idea for STL to throw
  56. exceptions when the user inserts something stupid, then let's lobby to
  57. make that a part of the standard. Otherwise put the test in the user
  58. code, not into a custom STL.
  59.  
  60. Cay
  61. horstman@cs.sjsu.edu
  62. ---
  63. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  64.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  65.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  66.